In high-speed layer-2/layer-3 network nodes (e.g. Internet protocol—IP routers), the majority of packet processing normally occurs as each packet enters the node (referred to as ingress processing). Such ingress processing typically includes forwarding table look-up and routing control for conveying data traffic (e.g. packets) through a switch fabric of the node to an appropriate egress port. In the case of multicast traffic, replication of packets is frequently also performed during the ingress processing, along with any translation services that may be needed, for example, to support the transport of traffic between heterogenous DiffServ domains. A minimal amount of egress processing is typically performed as each packet leaves the switch.
As demand for highly scalable, multicast-capable switches increases, it becomes increasingly desirable to reduce the ingress processing requirements of the node. A known method of accomplishing this involves pushing some functionality onto the fabric and/or increasing the egress processing functionality.
For example, a multicast capable fabric is known which alleviates packet replication requirements of the ingress processing, by replicating multicast traffic to the destination egress interfaces within the fabric itself (many methods may be used here, such as a shared memory fabric). Typically, this is accomplished by defining an intra-switch multicast group (which is an entirely intra-switch construct, and should not be confused with any external multicast groups mapped across the network itself), and assigning one or more egress interfaces to the intra-switch multicast group. For example, an intra-switch multicast group may be defined between an ingress interface A and egress interfaces X, Y and Z. Packets received by the intra-switch multicast group, through ingress interface A, are replicated and forwarded to each of the egress interfaces X, Y and Z, each of which, in turn, is then responsible for replication of the data traffic to one or more respective egress ports or logical connections, as required.
This arrangement removes traffic replication from the ingress processing, and thereby produces a processing architecture that is more balanced between the ingress and egress sides of the node. However, information identifying a source of the multicast traffic (e.g. an ingress port through which the traffic is received by the node) is not available to either the switch fabric or the egress interface. As a result, an egress interface is unable to distinguish between packets of different multicast traffic flows, and thus cannot provide flow-specific routing of multicast traffic to respective egress ports or logical connections. Consequently, each egress interface must be uniquely associated with a single intra-switch multicast group, and segregation of multicast traffic flows handled during ingress processing. This arrangement severely limits the number of multicast groups that can be mapped through the switch fabric. It is therefore common for external multicast groups (ie IP or VLANs) to exhaust the capabilites of the switch fabric to support separate multicast groups.
Accordingly, a method and apparatus that enables overloading of the switch fabric to facilitate enhanced scalability of a multicast capable switch having a balanced processing architecture remains highly desirable. In this context, the term “overloading the switch fabric” shall be understood to refer to a state in which an egress interface participates in two or more intra-switch multicast groups with non-overlapping logical egress port replication requirements.